Open messaging gateway

ABSTRACT

A messaging gateway ( 1 ) has a network node layer ( 20 ) which interface with mobile devices and manages context for them. A gateway node layer ( 30 ) controls access to applications and other functions such as billing. An applications node layer ( 25 ) provides requet/response mechanisms for access to applications on external servers. The network node layer ( 20 ) has a number of adapters, each associated with a type of mobile device. The gateway node layer ( 30 ) has nodes with access brokers which control access to applications according to user subscriptions, and responses are split up and routed according to adapter capabilities.

INTRODUCTION

[0001] The invention relates to a messaging gateway for use by mobilenetworks.

PRIOR ART DISCUSSION

[0002] At present, it is often the case that a new access mechanism isneeded for each new user device technology. This results in arequirement for skilled developers and use of toolkits and IDEs whichincrease commitment to a single technology. Conversion systems have beendeveloped to address these problems, for example systems for Web-basedautomatic translation of HIML to WAP or CHTML. However this approachoften provides only short-term benefits and also suffers from theproblem of allowing a low degree of interactivity. Also, the linkagesthrough the translation functions are relatively easy to break. Inanother approach, there is XML-centric automatic translation in whichXML is translated into formats such as WAP or HTML. However, thisapproach does not provide support for different degrees ofinteractivity, and there is little user context support.

[0003] The invention addresses these problems.

SUMMARY OF THE INVENTION

[0004] According to the invention, there is provided a messaging gatewaycomprising:

[0005] a network node layer comprising means for interfacing with usermobile devices of a plurality of different cornmunication standards toreceive content or service requests from the mobile devices and to routeresponses to the devices;

[0006] a gateway node layer comprising means for routing the requestsand the responses and for modifying them according to device technologyand content attributes; and

[0007] an application access node layer comprising means for accessingcontent servers and application servers.

[0008] In one embodiment, the network node layer comprises means formanaging the context for a device making a request, and for convertingan input into a Web request using input data, device context, andapplication context.

[0009] In another embodiment, the network node layer comprises means foradding user and location context to requests.

[0010] In a further embodiment, the network node layer comprises meansfor translating responses into a device-specific format using responsedate, device context, and application context.

[0011] In one embodiment, the network node layer comprises means forupdating and storing context between device interactions.

[0012] In another embodiment, the network node layer comprises aplurality of adapters, each associated with a type of mobile device.

[0013] In a further embodiment, the gateway node layer comprises meansfor controlling access to Web applications according to usersubscription, in which responses are split up and routed according toadapter capabilities, content attributes, and user-specified rules.

[0014] In one embodiment, the gateway node layer comprises means formanaging a register of adapter capabilities and of currently accessibleadapters for each user.

[0015] In another embodiment, the gateway node layer comprises means fortranslating service values placed by applications, and for routing thetranslated data to external systems.

[0016] In a further embodiment, the application access node layercomprises means for an API to allow alternative interfaces forinteractive applications.

[0017] In one embodiment, the network node layer, the gateway nodelayer, and the application access node layer comprise means forcommunicating with each other using an XML-compliant markup language.

[0018] In another embodiment, in said markup language, content isdefined in elements, in which a root element is an abstraction of amobile device screen.

DETAILED DESCRIPTION OF THE INVENTION BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The invention will be more clearly understood from the followingdescription of some embodiments thereof, given by way of example onlywith reference to the accompanying drawings in which:—

[0020]FIG. 1 is a diagrammatic representation showing context of agateway of the invention;

[0021]FIG. 2 is a diagram illustrating architecture of the gateway;

[0022] FIGS. 3(a) and 3(b) are diagrams showing alternative routesthrough the gateway;

[0023]FIG. 4 is a diagram illustrating signals for an interactiveapplication;

[0024]FIG. 5 is a diagram illustrating interaction with USSD data; and

[0025]FIG. 6 is a diagram illustrating a gateway hardware configuration.

DESCRIPTION OF THE EMBODIMENTS

[0026] Referring to FIG. 1, an open messaging gateway (OMG) 1 allows Web(HTTP) applications and mobile network (SMPP) applications to send andreceive messages such as short messages. The gateway 1 removes thecomplexity of the underlying messaging network from the applicationdeveloper.

[0027] In addition to these core functions the gateway 1 provides a setof supporting service management functions. Support is provided forservice level billing and access management. The product architecture ishighly scaleable to manage the ever-increasing number of messagingapplications and the volume of transactions that they will generate. Thegateway comprises a high-availability hardware configuration to ensureno loss of service in the event of a single point of failure.

[0028] The gateway 1 may interface with the following in the user domain(some of which are shown in FIG. 1):—

[0029] a cell broadcast centre (CBC) 2,

[0030] a WAP gateway 3,

[0031] a USSD server 4,

[0032] a multi-media services centre (MMSC) MM7,

[0033] a number of SMSCs 5 via a messaging applications router 6 ordirectly, and a foreign subscriber gateway 7 via the router 6.

[0034] In the application domain the gateway 1 may interface with:—

[0035] messaging services 10 via the internet or an intranet, and

[0036] SMS applications 11.

[0037] On the network (user) side, the devices may be referred to as“micro” devices because they are small, more “personal”, and have lowerlevels of processing power than traditional counterparts in thefixed-line Internet domain. There is a wide range of both capabilitiesand access protocols. Micro device have displays which range from simpletext-only LCD displays in low-end handsets through to high resolution,high colour TFT displays in laptop computers. In most cases, phone-basedmicro devices haveonly a limited ability to run scripts and decodecompressed and encrypted data. However, PDAs and laptop computers haveprocessors many times more powerful and are capable of decodingstreaming multimedia feeds and complex security protocols. Typically,phone-based micro devices are built with limited data storagecapabilities. PDAs and smart phones may have several megabytes andlaptop computers may have several gigabytes. Presently, micro devicesare using SMS, USSD and CSD technologies to connect to the WirelessInternet. Data transfer rates are slow and the device only sets up adata connection when initiated by the user. Shortly we will see devicesusing 2.5G technologies such as GPRS and EDGE working at much higherdata rates. Many of these devices will offer an ‘always on’ capability,enabling them to receive Wireless Internet content without the userhaving to actively establish a data session. In the future, we will seenew 3G devices that offer even greater data transfer rates. Thesedevices may well be true IP devices offering an ‘always on’ connectiondirectly to the Internet.

[0038] As the Wireless Internet grows and attracts an ever more diverseset of users with differing requirements it is likely that we will seethe range of micro devices expanding in response. Without a structuredapproach, providing compatible Wireless Internet services is going tobecome increasingly more difficult.

[0039] Referring to FIG. 2 the architecture of the gateway 1 is shown.The architecture is modular, in which resource-intensive translationfunctions are separate from interfacing functions. There is a user-sidenetwork node layer 20 having SMPP, USSD, JMS, and MM7 interfacing nodes.On the application side there is layer 25 of SMPP, MDML, SMAP, and MM7access nodes. Internally, the gateway 1 comprises gateway nodes 30,namely:

[0040] a charging node 31,

[0041] a billing node 32,

[0042] a content routing node 33,

[0043] a content translation node 34,

[0044] a data access node 35,

[0045] an archive node 36,

[0046] an authentication node 37, and

[0047] an authorisation node 38.

[0048] A routing interface 50 allows access by the data access node 35to a data store 55.

[0049] The gateway nodes 30 provide application and network interfaces,and a series of configurable routing, validation, and filteringfunctions that provide content and routing management of all messagingtraffic that passes through the gateway 1.

[0050] The modular nature of the architecture supports the rapiddeployment of additional network and application adapters, allowing newservices to be readily provided over multiple interfaces. In addition,the flexible validation and filtering capabilities provided by thegateway 1 allow highly configurable routing of message traffic through aseries of processing nodes in the gateway 1, as shown in FIGS. 3(a) and3(b). This routing allows operators to provide highly complex andinnovative services with minimum configuration and initial cost.

[0051] The service provided by the gateway 1 in each case is determinedby the path taken through the available pool of gateway nodes 30. Eachnode represents a block of functionality, implementing in one case forexample a filtering function, in another, a content transformation, inyet another, analysis of the destination address to provide routing. Anadvantage of the gateway 1 is the use of a standard API framework forthe nodes 20, 25, and 30, which makes the creation of additional nodesimplementing new functionality, a relatively straightforward andcost-effective process. The validation nodes are configurable and allowoperators to guarantee confidentiality, integrity and authentication ofall messaging traffic.

[0052] The gateway 1 provides a unique message identifier for eachmessage, which is assigned on message submission into the gateway 1.Mapping between network platform message IDs (e.g. SMSC message IDs) ishandled automatically by the gateway 1.

[0053] The access node layer 25 performs the following interfacing:—

[0054] Short Message Peer to Peer (SMPP)

[0055] Allows SMPP ESMEs to connect to the gateway 1

[0056] Supports SMPP version 3.3 and 3.4

[0057] Transparent Mode: acts as SMPP relay, windowing performed on SMSC

[0058] Non-transparent mode: acts as SMSC with local windowing and localacknowledgements

[0059] Message administration support

[0060] Load throttling and rating functions

[0061] ESME management interface for deployment, access control andmessage routing

[0062] Converts MO plaintext SMS and USSD into HTTP requests in MDMLformat

[0063] Converts MDML HTTP responses into MT plaintext SMS or USSD

[0064] Manages an interactive session on behalf of the SMS or USSDsubscriber

[0065] Supports web access to ringtones and picture messaging

[0066] Provides push interface to trigger interactive SMS session with asubscriber

[0067] Micro Device Markup Language (MDML)

[0068] The layer 25 accesses interactive applications over SMS and othermobile technologies. Applications can be written in Micro Device MarkupLanguage (MDML), a Logica Mobile Networks PLC proprietary XML format formobile applications. It allows developers to produce applications veryquickly using web development techniques and then to access theseapplications over HTTP from a variety of transport mechanisms includingplaintext SMS and USSD. The gateway 1 provides the automatic conversionbetween MDML and native wireless formats. This capability can easily beextended through the addition of nodes, to deliver for example, a WAPinterface or a cHTML interface.

[0069] MDML greatly simplifies the process of creating wirelessapplications, without needing to be aware of the specifics of bearerssuch as SMS. As an example, a ringtone download can be achieved in justsix lines of MDML: <panel title=”myring”> <soundsnippet alt=”my tune”format=”GSM-NOKIA-RINGTONE” link=”mytune.rtt”/> </panel>

[0070] The ringtone in “mytune.rtt” can be accessed simply be sending anSMS text “command” or selecting a USSD menu option. In each case, thegateway 1 performs seamless conversion between the underlyingapplication as expressed in MDML and the formats understood by eachwireless data technology.

[0071] A further example is a simple interactive quiz application usingSMS. This is illustrated in FIG. 4. A question based on the MDMLtemplate is adapted to a plaintext Short Message by the gateway 1 androuted to the subscriber. The subscriber responds with an answer, andthe OMG processes the response, selecting the correct MDML template todeliver the result.

[0072] SMS Push

[0073] The gateway 1 supports the pushing of MDML content from theapplication to the subscriber. In such a scenario, the gateway 1receives a HTTP POST containing the MDML content. The gateway 1 performsverification of the sending application based on IP address and accountinformation present in the MDML, and then forwards the content onto thesubscriber. The gateway 1 can also handle context information within theMDML. This allows a session to be initiated with the user for subsequentpull interaction. For example, an application might push details of anewsflash to the subscriber, and the subscriber will subsequently pulldown more detailed information on the news story.

[0074] In addition, the gateway 1 can handle MDML link information inthe Pushed data. In this scenario, the application does not push contentdirectly, but pushes a link to the relevant content. The gateway 1retrieves the page specified by the link, and sends this content to theuser.

[0075] Short Message Application (SMAP) Protocol

[0076] SMAP is an XML protocol from the SMS forum that providesequivalent functionality to SMPP over a variety of web protocolsincluding HTTP. This will allow developers to write applications thatsend and receive SMS messages using a simple XML format, with:

[0077] XML parsing of SMAP messages,

[0078] conversion of SMAP requests to and from internal gateway 1message formats, and

[0079] application provisioning and access control.

[0080] In the network node layer 20, the gateway 1 supports ShortMessage Peer-to-Peer (SMPP) protocol and unstructured SupplementaryServices Data (USSD) functionality.

[0081] For SMPP there is full Support for SMPP version 3.3 and 3.4, fullwindowing protocol, transparent support for Large Messages, and MessageCancel, Update and Query operations.

[0082] The gateway 1 can make a direct SMPP connection to the SMSC, orit can be deployed together with the Messaging Application Router (MAR)6 to provide support for multiple SMSCs 5, and for interfaces tonetworks supporting different wireless technologies.

[0083] For USSD, the gateway handles USSD over SMPP version 3.3 to aUSSD server, USSD session management, application routing capability,protocol conversion to SMS and interactive applications, and USSD phase2 primitive support.

[0084] This interface allows the gateway 1 to provide a top-level menufor an operator's USSD services. In this scenario, the gateway 1 isresponsible for routing subscriber requests to the correct applicationsand for maintaining a top-level menu for subscribers. Data from theapplications is routed back to the subscriber device through the SMSC asshown in FIG. 5.

[0085] The following describes the gateway nodes 30 in more detail.

[0086] Filter Node 39

[0087] This is a generic node used to process messages and forward themin a structured fashion. The filter node 39 can modify or delete amessage but cannot reroute messages or generate new ones.

[0088] Billing Node 32

[0089] The billing node generates Call Detail Records (CDRs) for offlineprocessing. It is flexible and fully configurable for both standard andcustom billing events. The CDR format can be configured on a per-nodebasis and the data elements within the CDR are extracted from thestandard OMG message format using a mixture of preset andoperator-configurable extraction rules. Typical contents of a CDRinclude Message Source and Destination, Timestamp, Delivery Parameters,Device Type, and can include the actual Text.

[0090] Charging Node 31

[0091] This node provides a prepaid billing interface to a PSA (prepaidservice agent). The interface uses the PSA PSP-CAP (Content ApplicationProtocol), providing content charging support. The PSA processes creditchecking and adjustment requests from the external system, maintainingcontact with the Intelligent Network Platform (INP) to ensure that thesubscnber's credit will never become negative. The PSA produces call orevent detail records for all of its transactions. These are sent to anINSS CDR/EDR Loader to be made available to the customer careinterfaces. The node 31 interfaces to the PSA to generate a chargingevent; passes service context parameters to a PSA interface; allowsconfiguration of standard charges per destination, service context andbilling context, and actions on success and failure.

[0092] Database Node 35

[0093] This node has two related functions—updating the database 55 withselected contents of a message and updating a message with dataextracted from a database. Each database node operates on a specifictable within one database using a pre-configured database operation. Adatabase node designer tool allows an administrator to specify thedatabase name, the table name, database access control parameters, theSQL command to be used, gateway message fields to be used in the SQLcommand, and gateway message fields to be updated on successfulcompletion of the comrnand.

[0094] Authentication Node 37

[0095] This is a pre-configured database node that authenticates asource address against the gateway access control database.

[0096] Authorisation Node 38

[0097] This is a pre-configured database node that validates a messageagainst a configurable set of authorisation criteria. These includedestination address, source address, service context, message size andcontents, and external “anti-spam” components.

[0098] Router Node 33

[0099] This node routes messages to other nodes based on messagecontents, system parameters and a configurable routing algorithm. Arouter node can be configured to route messages based on loading,service context, address information, and custom rules.

[0100] Archive Node 36

[0101] This node provides a standard interface through which messagescan be archived for administrative or user management reasons. Thearchive can be a simple message log or else a fully functional messagestore. In the latter case, a fully managed solution can be provided,whereby all short messages transmitted by or delivered to the user arearchived and the delivery status of these messages is updated by the OMGas delivery reports and status information passes through the system.

[0102] Content Translation Node 34

[0103] This is a specialised set of filter nodes that allow the operatorto perform custom operations on message content. There is also anaddress translation node which allows the operator to modify a source ordestination address based either on configurable rules or a databaseoperation. Also, a character-set translation node provides a standardmechanism for handling character set translations. A number of characterconversions nodes are provided and these can be supplemented with customconversion nodes. GSM 7-bit to and from ASCII conversion nodes areprovided. Also, a keyword conversion node converts keywords and contentaccording to configurable rules. This can be used to change theinterface of an application to conform to a standard set of guidelinesor to provide a mechanism for routing messages. Each node can beconfigured to:

[0104] set service context parameters based on positional keywords inthe message text,

[0105] convert selected keywords in the text to specified alternatives,and

[0106] match an entire message text and replace it with an alternativetext.

[0107] The gateway node layer 30 comprises a set of applicationtemplates which provide a web-based front end for simple applicationdevelopment. The templates are available for information and competitionapplications and dramatically reduce application development time forthese types of application as they remove the need for applicationdevelopers to have any XML skills. The gateway layer and serviceadministration interfaces provide the tools to manage the applicationscreated using these templates.

[0108] The gateway node layer 30 also comprises the followingadministration interfaces:

[0109] Configuration Manager

[0110] This allows the operator to add and remove nodes from the systemand to configure the distribution of functionality across the system. Italso allows the operator to specify configuration parameters forindividual nodes.

[0111] Deployment Manager

[0112] This is used to create nodes from node definitions and to groupnodes together to provide specific deployment configurations.

[0113] Node Design Tool

[0114] This provides a graphical interface through which new nodesdefinition can be created. The designer can select the base type of thenode definition and then perform type-specific configuration. A standardOMG node type such as the database access node is integrated with thedesign tool so that the designer can easily specify the message fieldsto be used and the SQL parameters to be configured.

[0115] Service Administration

[0116] This allows the service administrator to create new messagingservices and specify the parameters that allow the gateway 1 to routemessages to these services. A full set of user administration functionsis provided so that new service administrators can be created andmanaged.

[0117] Operator Interface

[0118] Provides a mechanism for starting and stopping the OMG andchecldng its current status.

[0119] The hardware of the gateway 1 comprises a number of HP's L-Class(rp5400) servers. This is a reliable platform, with scalability andredundancy. The software comprises HP-UX and the Apache Tomcat Javaruntime environment and Web Server. The gateway layer comprises a fullyresilient n+1 configuration, including the following elements, as shownin FIG. 6:

[0120] gateway messaging platforms,

[0121] a Storage Area Network (SAN), and

[0122] an IP load balancing hardware (Cisco Local Director™).

[0123] The SAN meets the requirements for shared storage betweenmultiple gateway servers. SAN design consists of a pair of BrocadeFibre-Channel switches and a mix of conventional and solid state storageto provide a resilient, highly available and high-performance storage.The mix of storage (conventional and solid state) is for performancereasons. The session data requires low latency in order to minimise theresponse time to any individual message being handled. Conventionalstorage is appropriate for all the remaining shared data.

[0124] A fully duplicated Cisco Local Director 416 configuration is usedto allow IP connections from the messaging infrastructure to beload-shared over the OMG platforms.

[0125] Within the gateway 1 the nodes 20, 25, and 30 communicate witheach other using the Micro Device Mark-up Language (MDML). The networkaccess nodes 20 comprise a number of technology adaptors, eachresponsible for allowing services and content to be delivered to aspecific class of micro device including:

[0126] SMPP, OIS and EMI protocols for SMS via Logica, Sema and CMGSMSCs respectively

[0127] SMPP for USSD via Logica's USSD Server

[0128] WML for WAP devices

[0129] HTML

[0130] cHTML for i-Mode phones

[0131] SMTP for e-mail delivery

[0132] Each of these device classes has different capabilities anddifferent methods of connecting to the wireless internet. The primaryfunction of each of the technology adapters is to ‘shelter’ applicationand content developers from these differences, allowing them to workwith a standard, micro device, interface. In order to do this,technology adapters for less capable micro devices (such as SMS-onlyphones) build this additional functionality into the network. As newclasses of micro device come to market, new technology adapters will becreated. This will allow new devices to access existing services withoutthe need to redevelop and test existing content and application code.

[0133] The gateway nodes 30 which handle messaging each comprises anaccess broker which performs a number of tasks, including:

[0134] maintenance of a subscriber register, the services to which theyhave subscribed and their preferences,

[0135] policing of user access to applications and content, ensuringusers are only able to access services to which they have subscribed,

[0136] where a subscriber has access to a range of micro devices,routing content to the most appropriate, and

[0137] interface to billing and advertisement engines.

[0138] The access node layer 25 is where wireless Internet applicationsand content resides. Fixed content is formatted as MDML Web pages thatare provided to the access broker by a standard Web Server platform.Dynamic content is provided using industry standard Java server sidetechnology, i.e. Java Servlets and JSP.

[0139] Applications also send and receive data to and from thetechnology adapters using MDML and HTTP. To minimise the effort requiredto generate MDML from within application code the framework includes aJava based MDML API. However, as MDML is an open specification, it isalso possible develop MDML compliant applications using in-house code ordevelopment environments other than Java.

[0140] Each technology adapter converts between a specific devicetechnology and the micro device protocol. A technology adaptor has thefollowing core functions:

[0141] provision of a receiver and transmitter giving access to theunderlying network transport mechanism for the device,

[0142] translation of incoming messages into MDML requests that are sentto the access broker via HTTP ‘post’ messages,

[0143] translation of MDML responses from the access broker into theformat used by the underlying network transport mechanism, and

[0144] management of user and device context—this enables users to enterthe minimum number of keystrokes required to access the services theyrequire.

[0145] In the gateway node layer 30 the access broker:

[0146] brokers user access to content and applications for ‘pull’ typeoperations, and

[0147] brokers application access to user's micro devices for ‘push’type operations.

[0148] This allows users, service providers, content providers andapplication developers to specify which services are available to whichusers and on which devices. Both pre-paid and post-paid billing forcontent and services is also managed by the access broker.

[0149] A request from a technology adaptor in the layer 30 is dealt withby an access broker in the layer 30. On receiving a request, the accessbroker:

[0150] identifies the associated application,

[0151] checks user subscription to the application,

[0152] performs any pre-access checks and debits the user's account ifnecessary,

[0153] forwards the request to the application, performing anyre-routing and URL translation required.

[0154] On receiving a response, the access broker:

[0155] parses the message,

[0156] performs any billing or charging on the panel,

[0157] generates advertising content based on the applicationinformation and the panel contents,

[0158] determines where individual components of the message should besent depending on the available device adaptors, and

[0159] assembles and sends the individual message components to theappropriate adapters.

[0160] Applications are defined as a set of MDML pages with associatedlogic, image and sound files. An application is defined in anapplication configuration file that specifies the following:

[0161] the application name,

[0162] the style-sheets and device configurations associated with theapplication,

[0163] the locations of the application's associated files,

[0164] its billing capabilities, and

[0165] images and icons used to identify the application to the user(e.g. on a personalisation web page or in a PDA folder).

[0166] An application's files reside in a directory hierarchy that canbe packaged up and deployed in a new location without any portingconstraints.

[0167] There are many ways that applications and content can bedeveloped. An application consists of both MDML content and logic. Thelogic resides in a series of Java Beans that are invoked automaticallywhen a given action is triggered by the user. A standard mappingmechanism is used to ensure that all actions either link to a new panelor are handled by a Java Bean. This allows an application developer tosimulate dynamic behaviour using either static panels, JSP or both andthen transparently migrate to a more interactive solution without anyre-deployment problems.

[0168] Micro Device Mark-Up Language

[0169] MDML provides a simple abstract mechanism for defining mobiledata to be presented to a user over a variety of devices. It is a‘content only’ format—formatting and styling have been excludeddeliberately in order to provide a definition that is both device andprotocol independent. MDML allows a content editor (or a dynamic contentgenerator) to:

[0170] define content for micro devices in a hierarchical fashion,

[0171] associate actions and links with content,

[0172] define advertising related instructions for content, and

[0173] specify billing mechanism for content.

[0174] Since MDML is an XML-compliant data format, it is possible totranslate XML data feeds into MDML using standard style-sheettechnology. It is also possible to translate MDML into HTML and WMLusing style-sheets.

[0175] Content Definition

[0176] MDML allows editors to create simple text-based content. Editorscan also associate a set of images and sound files with the content. Theroot element of all MML content is a panel. A panel can be regarded asan abstraction of the screen on the mobile device. A panel contains oneof the following elements:

[0177] Text—Character data arranged in paragraphs.

[0178] Menu—This defines a menu of items from which the user can select.

[0179] List—This defines an ordered list of items which may or may notbe selectable.

[0180] Form—This is a panel through which the user can enterinformation.

[0181] Table—A tabular set of information.

[0182] A panel element can be associated with sound and image elements.Sound elements can be defined as either short duration sound snippetsthat can be transferred to the micro device over standard communicationlinks or sound streams that must be accessed by a different mechanismsuch as a streamed voice connection or an mp3 device. Image elements aredefined in an image set. An image set is a set of image files containingdifferent versions of the same image. These versions may be in differentencoding formats (e.g. GIF or WBMP) and of different sizes. They eachhave a set of attributes that define:

[0183] The encoding format

[0184] The image size

[0185] The allowable transformations for this version of the image

[0186] This provides a mechanism that allows different images to be sentto different devices, thus enabling the content editor to control theappearance of the image precisely.

[0187] Linking and Actions

[0188] Elements can also have actions and links as attributes. An actionattribute defines an action that can be performed on the element (e.g.selection). A link attribute defines another MDML panel to which controlis transferred automatically when it is triggered. A panel can alsodefine action elements. Action elements are triggered by the user insome device-specific manner. As with an action attribute, an actionelement may have an associated link that is accessed automatically whenthe action is trigged.

[0189] Advertising Support

[0190] A panel can have associated with it a set of elements definingthe advertising context of the panel. These define whether advertisingis supported for the panel and either define a link from whichadvertising content can be extracted (e.g. a sponsor's message) or elsedefine categories which can be used to determine advertising for thepanel.

[0191] Content Billing

[0192] MDML defines elements that determine how billing is performed onthe panel. Editors can define the type of billing for a panel and candefine values for the billing itself. Billing elements can containeither a numeric value or a category. A numeric value correspondsdirectly to the amount that should be debited from the users account. Acategory (e.g. PREMIUM or SPORT) determines which user profile the usermust belong to in order to access the content.

[0193] It will be appreciated that the applications framework 1 supportsdevice-to-server interaction in a versatile and stable manner. It allowsa high degree of user interactivity, and also excellent personalisationbecause of storage of user contexts. The framework also allows use of awide range of access devices. Another important advantage is thatadaptation is based on the actual features of the access devicetechnology so that there is effectively “seamless” access to frameworkcontent from different devices. Regarding the content made availablethrough the framework, this includes interactive applications anddynamic content using JSP and MicroWeb APIS. There is excellent contentbrokering and attribute-based routing as well as enhanced advertisingand billing capabilities.

[0194] The invention is not limited to the embodiments described but maybe varied in construction and detail.

1. A messaging gateway comprising: a network node layer comprising meansfor interfacing with user mobile devices of a plurality of differentcommunication standards to receive content or service requests from themobile devices and to route responses to the devices; a gateway nodelayer comprising means for routing the requests and the responses andfor modifying them according to device technology and contentattributes; and an application access node layer comprising means foraccessing content servers and application servers.
 2. A messaginggateway as claimed in claim 1, wherein the network node layer comprisesmeans for managing the context for a device making a request, and forconverting an input into a Web request using input data, device context,and application context.
 3. A messaging gateway as claimed in claim 2,wherein the network node layer comprises means for adding user andlocation context to requests.
 4. A messaging gateway as claimed in claim2, wherein the network node layer comprises means for translatingresponses into a device-specific format using response date, devicecontext, and application context.
 5. A messaging gateway as claimed inclaim 2, wherein the network node layer comprises means for updating andstoring context between device interactions.
 6. A messaging gateway asclaimed in claim 1, wherein the network node layer comprises a pluralityof adapters, each associated with a type of mobile device.
 7. Amessaging gateway as claimed in claim 6, wherein the gateway node layercomprises means for controlling access to Web applications according touser subscription, in which responses are split up and routed accordingto adapter capabilities, content attributes, and user-specified rules.8. A messaging gateway as claimed in claim 1, wherein the gateway nodelayer comprises means for managing a register of adapter capabilitiesand of currently accessible adapters for each user.
 9. A messaginggateway as claimed in claim 1, wherein the gateway node layer comprisesmeans for translating service values placed by applications, and forrouting the translated data to external systems.
 10. A messaging gatewayas claimed in claim 1, wherein the application access node layercomprises means for an API to allow alternative interfaces forinteractive applications.
 11. A messaging gateway as claimed in claim 1,wherein, the network node layer, the gateway node layer, and theapplication access node layer comprise means for communicating with eachother using an XML-compliant markup language.
 12. A messaging gateway asclaimed in claim 11, wherein, in said markup language, content isdefined in elements, in which a root element is an abstraction of amobile device screen.
 13. A messaging gateway as claimed in claim 12,wherein, in said markup language, sound streams and images are definedas elements.
 14. A computer program product comprising software code forcompleting a message gateway as claimed in claim 1 when executing on adigital computer.